|
|
|
|
|
|
|
When the form requests that its controller obtain the data it needs to display to the user, the form controller communicates with business (or domain classes, for nonbusiness applications), including collection classes. Business classes manage the data that is meaningful to the user. In fact, business classes are typically based on the user's business knowledge, as well as on any business rules in the organization. |
|
|
|
|
|
|
|
|
Often, applications deal with several records at a time, for which collections of business classes are useful. Business class collections are, in a sense, queues or stores of data out of which form controllers request information to display. Collections can very well be seen as mini object-oriented databases that help shield (or encapsulate) the rest of the application from the relational database. Behind this shield, however, is even more of the story. |
|
|
|
|
|
|
|
|
Business classes, and their collections, communicate with Database Access classes to get data into and out of the database. The Business Rules Subsystem, then, communicates with the Database Access Subsystem through interface classes such as IPersistence, or in less complex applications, the IDBSubssytem interface class. As you saw on Day 19, The Database Access Subsystem, the Database Access Subsystem classes communicate with the database itself through any number of data access mechanisms, including ADO, RDO, DAO, ODBC API, VBSQL (SQL Server DBLIB and SQLOLE objects), data controls, and third-party data access mechanisms such as Oracle Objects. In addition, if you're developing a distributed Visual Basic application, you would have a proxy class that locally represents a remote subsystem (therefore, the word proxy). If you deploy the Business Rules Subsystem on a workgroup server, and the Database Access Subsystem on a separate enterprise server, you might find it convenient to create a data access proxy class, DBProxy, that handles the information persistence needs of the workgroup server on behalf of the enterprise server. In a fully qualified sense, DBProxy is a proxy interface class. This interface proxy class could also be helpful on regular two-tier client/server applications in which you create an ActiveX component to handle data access on the server (or even locally). |
|
|
|
|
|
|
|
|
Although it's certainly wise from a code reuse standpoint to not enable forms to directly communicate with the Database Access Subsystem, form controllers at times need to communicate with it. In fact, form controller classes aren't monopolized exclusively by the Graphical User Interface Subsystem in every situation. Sometimes a controller class can be the communication hub, of sorts, between the form business rules and the Database Access Subsystem. This is helpful when you're moving data in and out of a database, one record at a time, and no business rule processing occurs. Typical applications that might face this scenario include pure data entry applications in which the user is keying in information on a client machine, and that information is to be processed later |
|
|
|
|
|